The present invention relates to a system and method for transmitting objects between machines in a distributed system and more particularly relates to methods for invocation of remote methods in a distributed system.
Distributed programs that concentrate on point-to-point data transmission can often be adequately and efficiently handled using special-purpose protocols for remote terminal access and file transfer. Such protocols are tailored to a specific program and, therefore, do not provide a foundation on which to build a variety of distributed programs (e.g., distributed operating systems, electronic mail systems, conferencing systems, etc.).
While conventional transport services can be used as the basis for building distributed programs, these services exhibit many organizational problems, such as the use of different data types in different machines, lack of facilities for synchronization, and no provision for a limited programming paradigm.
Distributed systems usually contain a number of different types of machines interconnected by communications networks. Each machine has its own internal data types, its own address alignment rules, and its own operating system. This heterogeneity causes problems when building distributed systems. As a result, program developers must include in programs developed for such heterogeneous distributed systems the capability of dealing with ensuring that information is handled and interpreted consistently on different machines.
However, one simplification is afforded by noting that a large proportion of programs use a request and response interaction between processes where the initiator (i.e., program initiating a communication) is blocked waiting until the response is returned and is thus idle during this time. This can be modeled by a procedure call mechanism between processes. One such mechanism is referred to as the remote procedure call (RPC).
RPC is a mechanism for providing synchronized communication between two processes (e.g., program, applet, etc.) running on the same machine or different machines. In a simple case, one process, e.g., a client program, sends a message to another process, e.g., a server program. In this case, it is not necessary for the processes to be synchronized either when the message is sent or received. It is possible for the client program to transmit the message and then begin a new activity, or for the server program""s environment to buffer the incoming message until the server program is ready to process a new message.
RPC, however, imposes constraints on synchronism because it closely models a local procedure call within the calling process, which requires passing parameters in one direction, blocking the calling process until a called procedure of the server program is complete, and then returning a response. RPC thus involves two message transfers, and the synchronization of the two processes for the duration of the call.
The RPC mechanism is usually implemented in two processing parts using the local procedure call paradigm, one part being on the client side and the other part being on the server side. Both of these parts will be described below with reference to FIG. 1.
FIG. 1 is a diagram illustrating the flow of call information using an RPC mechanism. As shown in FIG. 1, a client program 100 issues a call (step 102). The RPC mechanism 101 then packs the call as arguments of a call packet (step 103), which the RPC mechanism 101 then transmits to a server program 109 (step 104). The call packet also contains information to identify the client program 100 that first sent the call. After the call packet is transmitted (step 104), the RPC mechanism 101 enters a wait state during which it waits for a response from the server program 109.
The RPC mechanism 108 for the server program 109 (which may be the same RPC mechanism as the RPC mechanism 101 when the server program 109 is on the same platform as the client program 100) receives the call packet (step 110), unpacks the arguments of the call from the call packet (step 111), identifies, using the call information, the server program 109 to which the call was addressed, and provides the call arguments to the server program 109.
The server program receives the call (step 112), processes the call by invoking the appropriate procedure (step 115), and returns a response to the RPC mechanism 108 (step 116). The RPC mechanism 108 then packs the response in a response packet (step 114) and transmits it to the client program 100 (step 113).
Receiving the response packet (step 107) triggers the RPC mechanism 101 to exit the wait state and unpack the response from the response packet (step 106). RPC 101 then provides the response to the client program 100 in response to the call (step 105). This is the process flow of the typical RPC mechanism modeled after the local procedure call paradigm. Since the RPC mechanism uses the local procedure call paradigm, the client program 100 is blocked at the call until a response is received. Thus, the client program 100 does not continue with its own processing after sending the call; rather, it waits for a response from the server program 109.
The Java(trademark) programming language is an object-oriented programming language that is typically compiled into a platform-independent format, using a bytecode instruction set, which can be executed on any platform supporting the Java virtual machine (JVM). This language is described, for example, in a text entitled xe2x80x9cThe Java Language Specificationxe2x80x9d by James Gosling, Bill Joy, and Guy Steele, Addison-Wesley, 1996, which is incorporated herein by reference. The JVM is described, for example, in a text entitled xe2x80x9cThe Java Virtual Machine Specification,xe2x80x9d by Tim Lindholm and Frank Yellin, Addison Wesley, 1996, which is incorporated herein by reference. Java and Java-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
In object-oriented systems, a xe2x80x9cclassxe2x80x9d provides a template for the creation of xe2x80x9cobjectsxe2x80x9d (which represent items or instances manipulated by the system) having characteristics of that class. The term template denotes that the objects (i.e., data items) in each class share certain characteristics or attributes determined by the class. A class thus defines the type of an object. Objects are typically created dynamically during system operation. Methods associated with a class are generally invoked (i.e., caused to operate) on the objects of the same class or subclass.
Because the JVM may be implemented on any type of platform, implementing distributed programs using the JVM significantly reduces the difficulties associated with developing programs for heterogenous distributed systems. Moreover, the JVM uses a remote method invocation (RMI) system that enables communication among programs of the system. RMI is explained in, for example, the following document, which is incorporated herein by reference: Remote Method Invocation Specification, Sun Microsystems, Inc. (1997), which is available via universal resource locator (URL) www.javasoft.com/products/jdk/1.1/docs/guide/rmi/spec/rmiTOC.doc.html.
FIG. 2 is a diagram illustrating the flow of objects in an object-oriented distributed system 200 including machines 201 and 202 for transmitting and receiving method invocations using the JVM. In system 200, machine 201 uses RMI 205 for responding to a call from object 203 to invoke a method on remote object 204 by converting the call, including an identification of the method and any parameters into a byte stream 207. While machine 201 is responding to the call from object 203, a process running on the same or another machine in system 200 may continue operation without waiting for a response.
Machine 202 receives the byte stream 207. Using RMI 206, machine 202 automatically converts it into executable bytecode to initiate the invocation of the method on object 204. RMI can also be used to transport objects within the distributed system for use in connection with processes executing on remote machines.
In order to perform RMI, these machines use code referred to as stubs and skeletons created by an RMI compiler. A stub resides on a client machine and includes a reference to a remote object and acts as a proxy for the remote object. The skeleton is also a proxy for the remote object but it resides on the server machine containing the remote object. Thus, the stub resides on a client machine making a call for invocation of a method of a remote object, and the skeleton resides on a server machine containing the remote object. In addition, remote objects are referenced via interfaces, which are collections of related constants and methods. The stub and skeleton typically must be type-specific based on the type of remote object involved in the call. Therefore, varying types of stubs and skeletons must exist for RMI involving varying types of objects. Stubs and skeletons are explained in for example, the following document, which is incorporated herein by reference: Jamie Jaworski, xe2x80x9cJava 1.1 Developer""s Guide, Second Edition,xe2x80x9d pp. 371-383, Sams.net Publishing (1997). They are also explained in the Remote Method Invocation Specification identified above.
Accordingly, a need exists for generic code for use in RMI involving varying types of objects.
A first method consistent with the present invention includes receiving a request to invoke a method of an object and determining the method to be invoked using a generic code. The method is invoked based on the determination, and an indication of the invoked method is provided.
A second method consistent with the present invention includes receiving a request to invoke a method of an object of a specific class and determining the method using a common process for all of the classes. The method is invoked based on the determination, and an indication of the invoked method is provided.
A third method consistent with the present invention includes receiving a request to invoke a first method of a first object and a second method of a second object being of a different type from the first object, and determining the first and second methods to be invoked using a common process. The first and second methods are invoked based on the determination, and an indication of the first invoked method and the second invoked method is provided.
A first apparatus consistent with the present invention receives a request to invoke a method of an object and determines the method to be invoked using a generic code. The apparatus invokes the method based on the determination and provides an indication of the invoked method.
A second apparatus consistent with the present invention receives a request to invoke a method of an object of a specific class and determines the method using a common process for all of the classes. The apparatus invokes the method based on the determination and provides an indication of the invoked method.
A third apparatus consistent with the present invention receives a request to invoke a first method of a first object and a second method of a second object being of a different type from the first object, and it determines the first and second methods to be invoked using a common process. The apparatus invokes the first and second methods based on the determination and provides an indication of the first invoked method and the second invoked method.